[Elastic Beanstalk] 拡張ヘルスモニタリングを試してみた

はじめに

AWSチームのすずきです。

先日のAWSのアップデートにより、Elastic Beanstalkのアプリケーション監視機能が強化されました。

拡張ヘルスモニタリング機能により、 ヘルスチェックの監視間隔の短縮（1分→10数秒毎）、ヘルスチェックステータスの詳細化（3段階→7段階）に加え、 専用の監視エージェント（EC2のAmazonLinuxにインストール）による、 CPU利用状況、空きディスク容量、アプリケーションの応答状況などの確認も可能となりました。

今回Elastic Beanstalk管理下のアプリケーション環境で、拡張ヘルスモニタリングを試す機会がありましたので、 その内容について紹介します。

参考

• AWSブログ: Elastic Beanstalk アップデート - アプリケーションの拡張ヘルスモニタリング
• AWSドキュメント: インスタンスと環境のヘルスの判定要素

事前準備

IAM設定

• Elastic Beanstalkの拡張ヘルスモニタリングに必要なIAM権限設定を行います。

Elastic Beanstalk Service Role

• AWSにより提供される監視システム、Elastic Beanstalk サービスで利用する権限を定義します。
• 今回、Elastic Beanstalkの「新規アプリケーションの作成」→「アクセス権限」→サービスロール:「新しいロールの作成」で生成したロールを利用しました。

• 「新しいロールの作成」で生成される「aws-elasticbeanstalk-service-role」には、以下のポリシーが付与されます。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticloadbalancing:DescribeInstanceHealth",
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:GetConsoleOutput",
"ec2:AssociateAddress",
"ec2:DescribeAddresses",
"ec2:DescribeSecurityGroups",
"sqs:GetQueueAttributes",
"sqs:GetQueueUrl",
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeAutoScalingInstances",
"autoscaling:DescribeScalingActivities",
"autoscaling:DescribeNotificationConfigurations"
],
"Resource": [
"*"
]
}
]
}

Elastic Beanstalk Instance Profile

• Elastic Beanstalk により起動するEC2インスタンスに付与するIAMロールを設定します。
• 今回の検証環境では、EC2インスタンスには、ポリシー「PowerUserPolicy」が付与済であったので、こちらをそのまま利用しました。
• Elastic Beanstalkの「新規アプリケーションの作成」でも、拡張ヘルスモニタリングに必要なIAM権限（cloudwatch:PutMetricData）を有すロールは生成されます。

プラットフォームの更新

• 拡張ヘルスモニタリングの利用には、バージョン2.0.0以降のAMIが必要です。
• 今回のアプリケーション環境、PHP 5.6の「v1.4.6」から、最新リリース「64bit Amazon Linux 2015.03 v2.0.0 running PHP 5.6」への更新を実施しました。

設定と確認

拡張モニタリングの有効化

• AWSコンソールのElastic Beanstalk のダッシュボード画面より、設定対象の「設定」画面を開きます。
• 「ヘルス」の設定画面を開きます。

• 「Health Permissions」として、「aws-elasticbeanstalk-service-role」を選択します。
• 適切なサービスロールが指定されなかった場合、拡張モニタリングのヘルスチェックが失敗し、デプロイに失敗します。
• ヘルスレポートのシステムタイプとして、「拡張」を指定します。
• 拡張モニタリングで監視対象とするメトリックスを指定します。
• 今回「Instance」の情報としてCPU関連を指定、「Environment」は全てのメトリックスを対象としました。

• 拡張モニタリングで指定したメトリックスは、Cloudwatchのカスタムメトリックスとして登録されます。
• カスタムメトリックスは、無償枠の10 メトリックスを超過すると、1メトリックスあたり月額0.5$の課金対象となります。特にEC2台数が多い場合、インスタンス指定の監視項目は精査する事をお奨めします。
• 拡張モニタリングを有効にし、設定を反映すると監視エージェントが有効化したEC2インスタンスへの入替が発生します。

モニタリング結果の確認

• AWSコンソールのElastic Beanstalk のダッシュボード画面より、設定対象の「モニタリング」画面での確認が可能です。
• 拡張モニタリングの結果は、「概要」「グラフの追加」より、「リソース」、「Cloudwatchメトリックス」を指定する事で表示されます。

Environment

• Rootファイルシステム使用率が確認出来るようになりました。
• アプリケーションの応答時間について、パーセンタイル表示が可能になりました。これまでの平均値、最大値では拾いにくい性能傾向が把握出来るようになりました。
• アプリケーション応答時間は、httpd、nginxのアクセスログ（監視エージェント用の専用ログが追加されます）が集計対象となり、ELBのメトリックより詳細な情報が期待出来ます。

• インスタンスの稼働ステータスについて、より細かい区分で拾える様になりました。

各Instance

• CPU使用率の詳細とロードアベレージの確認が可能になりました。
• IOwait, System, Userの各値が確認できる事で、CPU利用率が上昇原因をつかみやすくなりました。

ベーシックモニタの結果

• 拡張モニタリングを利用しない場合でも、AutoScallingGroupと、ELBのCloudwatchの以下のメトリックによる監視が行われています。

AutoScallingGroup

ELB

パーセンタイルグラフ

• EC2のインスタンスタイプの違いによる、パーセンタイルグラフの結果は以下の通り。
• Webサーバの性能判定に役立つ情報が得られます。

c4.large

• 稼働時間帯 〜13:45
• ApplicationLatencyP75：0.9前後
• ApplicationLatencyP90〜99.9：2.0〜3.0
• 75%のリクエストはレスポンス1秒以下。
• 99.9%のリクエストレスポンス3秒以下。

m3.medium

• 稼働時間帯 15:00〜17:00
• ApplicationLatencyP75：2.0〜3.0
• ApplicationLatencyP99：6〜8
• ApplicationLatencyP99.99：7.5〜10
• レスポンスに2秒以上を要したリクエスト25%存在。
• 1%のリクエストは6〜10秒と大幅悪化、サーバ性能不足と考えられます。

t2.medium

• 稼働時間帯 17:00〜
• ApplicationLatencyP75：1.0前後
• ApplicationLatencyP90〜99.9：2.0〜3.0
• c4.large環境とほぼ同等の傾向で、サーバ性能は十分と判定。

まとめ

今回紹介させて頂いたElastic Beanstalkの拡張モニタリング、Cloudwatchのカスタムメトリックスの実費のみで利用する事が可能です。 V2.0.0以降のプラットフォーム（AMI）への更新が可能な環境であればその導入は簡単に行う事ができ、インスタンスへのSSHログイン頻度を抑制できる効果も期待できます。

また、今回新たに確認出来るようになったパーセンタイルのグラフ情報は、サービス品質の判定に効果的と考えられますので、是非お試しください。